[HEVC] x265.EXE: mingw builds

[LigH.de]

I see in the developer mailinglist that Assembler implementations of kernel features keep arriving.

When would you estimate a speed comparison between an earlier and a current build getting interesting?
__

@ x265.cc:

16bpp builds postponed until further notice?

[Tommy Carrot]

I see in the developer mailinglist that Assembler implementations of kernel features keep arriving.

When would you estimate a speed comparison between an earlier and a current build getting interesting?

Well, it's slowly but surely getting faster. A 2 weeks old build finished my test in about 90 sec, the latest does it in 66 sec, with identical output. It's still much slower than x264 placebo preset, so there is still some work to to.

It is now faster than my 'reference' x265 build from aug 14, but the quality is still quite a bit worse, both visually and metrically (the psnr is 0.7-1.2 db lower).

[LigH.de]

A certainly promising signal for me is that it sometimes passes 90% CPU utilization of a QuadCore, with "conservatively" enabled per-frame parallelization (-F 3). There is headroom, I guess...

[El Heggunte]

I see in the developer mailinglist that Assembler implementations of kernel features keep arriving.

Yes, and ¡many!/¿most? of them are tagged for "Review Only"

When would you estimate a speed comparison between an earlier and a current build getting interesting?

I have no idea They still have so much to study and to learn...

For the time being, it's more interesting for us, the guinea pigs , to have an adequate Matroska muxer ( hello Mosu ) and an up2date+stable build of L-SmashSource ( hello VFR Maniac ^_~ ).

[LigH.de]

... and an up2date+stable build of L-SmashSource ( hello VFR Maniac ^_~ ).

And a current release of an FFmpegSource2 C-plugin r800+29 (hello qyot27).
__

... but the quality is still quite a bit worse, both visually and metrically (the psnr is 0.7-1.2 db lower).

Don't care too much about PSNR. It was already documented that x264's psychovisual enhancements will probably worsen the PSNR values, yet may look more convenient.

But if you say that it also looks subjectively worse, then this may indeed be an opinion to review.

[chie]

Msvc 11

[Brazil]

Anyone knows where to find GCC builds of recent versions of MP4Box and L-Smash ?
Or, at least, builds not using MSVC2010 or later runtimes.

[Selur]

up-to-date dynamic MP4Box builds are included in the nightly GPAC package: http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/
alternatively you can build it statically yourself using: https://github.com/rdp/ffmpeg-windows-build-helpers
L-Smash: no clue

[x265.cc]

@ x265.cc:

16bpp builds postponed until further notice?

The 16bit builds (the source code) are currently broken.

They will be available again (automaticly) if the x265 team fixes the sourcecode.

Probably i should upload the log files automaticly too. (and generate some "successful" (etc.)). messages.

[Brazil]

up-to-date dynamic MP4Box builds are included in the nightly GPAC package: http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/

But these builds require MSVC 2010 runtime. Hence my request.

There was a blog page (http://k4095-takuan.blogspot.de/p/blog-page_17.html) providing MP4Box and L-Smash GCC builds but it seems not to be available anymore

[El Heggunte]

@ Brazil:

L-Smash (source-code):

http://code.google.com/p/l-smash/

https://github.com/silverfilain/L-SMASH

https://github.com/l-smash/l-smash

Some pages ago, I uploaded an "experimental" build of L-Smash to this thread, but according to vhelp, it still is somewhat "problematic", HEVC-wise

MP4Box builds by X5-452: http://sada5.sakura.ne.jp/files/index.php?folder=TVA0Qm94

BTW, what do you have against the MSVC-RT redists?

[Brazil]

MP4Box builds by X5-452: http://sada5.sakura.ne.jp/files/index.php?folder=TVA0Qm94

Nice find, works a treat!
Thanks a lot

[El Heggunte]

MP4Box builds by X5-452: http://sada5.sakura.ne.jp/files/index.php?folder=TVA0Qm94

Nice find, works a treat!
Thanks a lot

You're welcome.

However you haven't answered my question

The VC-redists are small and don't screw the Registry,
differently from the overbloated subNET "virtual machines"

[Tommy Carrot]

... and an up2date+stable build of L-SmashSource ( hello VFR Maniac ^_~ ).

... but the quality is still quite a bit worse, both visually and metrically (the psnr is 0.7-1.2 db lower).

Don't care too much about PSNR. It was already documented that x264's psychovisual enhancements will probably worsen the PSNR values, yet may look more convenient.

But if you say that it also looks subjectively worse, then this may indeed be an opinion to review.

I know psnr doesn't always correlate with the quality, but it can be useful when there is no psychovisual stuff involved (afaik there is none in x265). However, as i said, it also looks noticably worse at similar bitrates. The older build retained significantly more details, and had better temporal stability.

[Jacobr]

To whom this may interest..............
---snap---

videocodec slhevc
  info "Strongene Lentoid HEVC"
  status working
  fourcc HM10
  fourcc HEVC
  fourcc HVC1
  driver dshow
  dll "hevcdecfltr.dll"
  guid 0x083863F1, 0x70DE, 0x11D0, 0xBD, 0x40, 0x00, 0xA0, 0xC9, 0x11, 0xCE, 0x86
  guid 0x658C5E1C, 0x58E1, 0x43CA, 0x9D, 0x10, 0x13, 0x73, 0x5D, 0x46, 0x55, 0x76
  out YV12

Thanks a lot for that, also for the apparent edit, as i tried to figure out the lines by myself and wasn't sure what's wrong with them ;p
It also works with smplayer obviously. one question tho, that picture of hevc+ac3 in avi, did the encode use bframes? back when i was stuffing h265 in avi, any encode with bframes = instacrash

ps, btw, the latest lentoid finally manages to decode my streams

[x265]

I see in the developer mailing list that Assembler implementations of kernel features keep arriving.

When would you estimate a speed comparison between an earlier and a current build getting interesting?

As part of the normal performance optimization we have a long list of performance critical functions that are being hand-optimized with assembly code. This and other performance optimization work will continue for many weeks.

Speed and quality comparisons with older x265 builds may be affected by changes in default values for certain options.

Tom

[El Heggunte]

Thanks a lot for that, also for the apparent edit, as i tried to figure out the lines by myself and wasn't sure what's wrong with them ;p
It also works with smplayer obviously. one question tho, that picture of hevc+ac3 in avi, did the encode use bframes? back when i was stuffing h265 in avi, any encode with bframes = instacrash

ps, btw, the latest lentoid finally manages to decode my streams

You're welcome
TBH, when I added the link to the default codecs.conf
( because it seems the most recent Mplayer builds by Redxii don't include it anymore ),
I accidentally erased one line of the HEVC entry , then later I had to do another edit =^.^=

To the best of my memory, that low-res encode of the Sintel Trailer doesn't have B-frames, because the first version of the Lentoid Decoder apparently didn't like a video stream without P-frames

Speaking of crashes:
the ASF-wrapped clip "Successful Mission" kills Mplayer IF you choose "-demuxer lavf"
Also, it requires "-ac a52" to be played correctly (or at all)

[x265]

We have a new stable version - 0.5



= New Features =
* x265 can now be built by Mac OS X clang compiler
* install/uninstall build targets (install-only for Windows)
* Our cmake scripts now build static and shared libraries
* --ref N is now supported for enabling multiple L0 references
* SSIM global statistic reporting (--ssim)
* CSV logging is now a core feature, introduced per-frame logging

= API Changes =
* "_t" suffix removed from public data types for POSIX compatibility
* public API is now versioned
* --cpuid meaning has changed from level to capability bitmap, same as x264
* param.bipredSearchRange has been removed (--bpredrange N)
* param.maxNumReferences has been added (--ref N)
* param.csvfn has been added (--csv FILENAME.csv)
* PSNR and/or SSIM reporting are optional (--[no-]psnr --[no-]ssim)
* x265_version_str exported string symbol with version (tag) info
* x265_build_info_str exported string symbol with compile info
* x265_encoder_get_stats() method for querying encoder statistics
* x265_encoder_log() method for writing to CSV log file
* x265_param_parse() method for configuring x265_param_t via strings

* x265 now requires cmake 2.8.8 or later in order to build
* Weightp options re-enabled, but feature is still unfinished
* param.rc.aqmode, param.rc.aqstrength for unfinished AQ support

= Improvements =
* x265 is deterministic at -F1 and separately deterministic for Fn>1
(ie: -F2 and -F12 will give the same outputs if all other args are same)
* We have adopted a bidir search more closely resembling x264's bidir
* Lookahead analysis now includes bidir candidates for B slice types
* Lookahead uses thread pool and wave-front block scheduling
* The "multiple of min CU size (4)" resolution requirement has been removed
* More x264 assembly is being used for motion search and bidir MC
* PSNR and SSIM are measured row-by-row after deblocking and SAO
* Use of Standard Template Library classes has been removed
* SIMD Vector Classes are no longer used for 8bpp primitives

= Upcoming improvements =
* support in CLI for reading YUV or Y4M on stdin (already in default)
* performance presets
* Main10 profile
* Weightp in lookahead, weight analysis adapted from x264
* lookahead worker thread
* Adaptive QP

[x265.cc]

We have a new stable version - 0.5

The 16bpp version is still broken for me. "x265_0.4.1+560-0666d56aaa42" is the latest working 16bpp version.

Aynway, thanks for the release.

x265\source\common\vec\ipfilter-sse41.cpp(1371): error C2440: '=' : cannot convert from 'void (__cdecl *)(int16_t *,intptr_t,pixel *,intptr_t,int,int,const int16_t *)' to 'x265::ipfilter_sp_t' [x265\build\vc11-x86_64\common\common.vcxproj]

x265\source\common\vec\ipfilter-sse41.cpp(1372): error C2440: '=' : cannot convert from 'void (__cdecl *)(int16_t *,intptr_t,pixel *,intptr_t,int,int,const int16_t *)' to 'x265::ipfilter_sp_t' [x265\build\vc11-x86_64\common\common.vcxproj]

The 8bpp x265 rev 0.5 binaries are available at https://x265.cc

[vhelp]

@x265 and team,
1. ty for the piping/stdin feature...made me and many others very happy. i can't wait until full avisynth support becomes available.

2. also, if i may ask, any chance of obtaining a list of all the min/max values for each of the param commands ?
this will help gui developers set their proper limits, i.e., --ref 1..15, --qp 0..32, and so on...for instance.

3. and, any chance of a stand-alone pipe/stdin-able decoder utility ? so that we can better review test encodes inside an avisynth script and timeline ?
currently, the only method i'm aware of is through TAppEncoder -b file.hm10 -o file.yuv which creates a huge yuv file, which sort of kills the mood, but is the only method available.

[vhelp]

el heggunte, great news for ffmpeg users. the latest ffmpeg v2.1 can now play raw hevc encodes and the mp4box muxed.mp4 and probably other muxed methods through ffplay...!!!

so, given that, do you think there is a way to pipe it into an avisynth script to view in a timeline ?

i'm trying to figure it out but can't get it working. i'd be happy with just using the raw hm10 file. but both would be great. thank you.

[vhelp]

@Jacobr
yep, seems your last demo source, "[HorribleSubs] Kyoukai no Kanata - 01 [720p].mp4" now plays when i use the latest ffmpeg v2.1 ffplay. it was a decoder issue on yours/my end. seems the decoders are getting better and better, finally.

[x265]

@x265 and team,
1. ty for the piping/stdin feature...made me and many others very happy. i can't wait until full avisynth support becomes available.

2. also, if i may ask, any chance of obtaining a list of all the min/max values for each of the param commands ?
this will help gui developers set their proper limits, i.e., --ref 1..15, --qp 0..32, and so on...for instance.

3. and, any chance of a stand-alone pipe/stdin-able decoder utility ? so that we can better review test encodes inside an avisynth script and timeline ?
currently, the only method i'm aware of is through TAppEncoder -b file.hm10 -o file.yuv which creates a huge yuv file, which sort of kills the mood, but is the only method available.

1 - You're welcome.
2 - Agreed. I've asked the team to provide min/max and type for all options where this isn't already specified in the documentation. There are a few such options. I think QP goes up to 48, btw... but like you, I had to discover this by trial and error.
3 - Will discuss with our team.

Tom

[El Heggunte]

can someone show me how to open an encoded .hm10 or muxed.mp4 file via avisynth script so i can scrub through the videos.

Raw hm10/hevc streams can be viewed via Avisynth's DirectShowSource in VirtualDub.
However you must be careful and (especially) not-so-lazy, man
First, decide which will be your preferred HEVC source filter and HEVC decoder.
For now, the Lentoid decoder works only with the Lentoid source filter, and
LAV Video works only with LAV Splitter (or with the MPC-HC standalone filters, take your pick).
Adjust the merits of the filters with Graphstudio or with RadLight Filter Manager 1.6.
Then create an AVS file similar to this:

DirectShowSource("zzzbinst.hevc", framecount=85, fps=30)
#ShowFrameNumber()
# WARNING: seeking + DirectShowSource = suckxsss

NOTE: you must specify the framecount and the framerate, otherwise your dog dies :–P

The quality of the test encode shown below suxxx very-much, but
since it's for educational use only, *anything goes* ^__^



Regarding MP4 sources, and according to LigH, the alpha build of FFMS2 by qyot27 should work.
Test it, this is the homework of the week for vhelp :–P

[Selur]

The 8bpp x265 rev 0.5 binaries are available at https://x265.cc

"64bit - 8bpp VC11" and "32bit - 8bpp VC11-legacy" do not work

I've asked the team to provide min/max and type for all options where this isn't already specified in the documentation. There are a few such options.

nice!

[x265.cc]

"64bit - 8bpp VC11" and "32bit - 8bpp VC11-legacy" do not work

I've got a lot of new cisco networking hardware today (i felt like it were christmas..) so the network conntection has been interrupted for some seconds (and killed the upload process). I'm sorry for that, and fixed it some minutes after your post.

Anyway thanks for the report

[Fllear]

x265.exe akiyo_cif.y4m -o output.hevc

Intel Core2Quad Q9000 (6M Cache, 4x2.00GHz); 4096 MB DDR2; Windows 7 Enterprise x64 SP1:

GCC 4.8.1: encoded 300 frames in 112.39s (2.67 fps), 28.59 kb/s, Global PSNR: 39.079
GCC 4.8.2: encoded 300 frames in 114.97s (2.61 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x86: encoded 300 frames in 92.08s (3.26 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x64: encoded 300 frames in 73.71s (4.07 fps), 28.59 kb/s, Global PSNR: 39.079

Intel Core i5-760 (8M Cache, 4x2.80GHz) ; 4096 MB DDR3; Windows 8.1 Enterprise x64:

GCC 4.8.1: encoded 300 frames in 65.98s (4.55 fps), 28.59 kb/s, Global PSNR: 39.079
GCC 4.8.2: encoded 300 frames in 66.89s (4.48 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x86: encoded 300 frames in 55.02s (5.45 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x64: encoded 300 frames in 43.45s (6.90 fps), 28.59 kb/s, Global PSNR: 39.079

Intel Core i5-3570k (6M Cache, 4x4.63GHz) ; 16332 MB DDR3; Windows 8.1 Enterprise x64:


VC11-x86: encoded 300 frames in 26.85s (11.17 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x64: encoded 300 frames in 21.00s (14.29 fps), 28.59 kb/s, Global PSNR: 39.079

[mindwin]

AMD Phenom II X3 720B (three cores at 2.8ghz) | Windows 7 x64 | 6GB DDR II

Used instructions:
using cpu capabilities: MMX2 SSE SSE2Fast LZCNT

Why it dont use SSE3 or SSE4A?

Cpu load very low, is about 45-55%

MinGW 32bit - encoded 300 frames in 109.47s (2.74 fps), 28.59 kb/s, Global PSNR: 39.079
VC11 32bit - encoded 300 frames in 109.58s (2.74 fps), 28.59 kb/s, Global PSNR: 39.079
VC11 64bit - encoded 300 frames in 95.95s (3.13 fps), 28.59 kb/s, Global PSNR: 39.079

[Selur]

Why it dont use SSE3?

Wild guess: Nobody, hasn't written any SSE3 specific code. -> Make a HUGE donation to the project, so they can hire someone to do it or wait till the basic code is working properly,...

[x265.cc]

Why it dont use SSE3?

Wild guess: Nobody, hasn't written any SSE3 specific code. -> Make a HUGE donation to the project, so they can hire someone to do it or wait till the basic code is working properly,...

nope.. see Fllear's screenshots (or the x265 repo).

Core2Quad Q9000 output (vc11/mingw):

x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64

@mindwin: LZCNT should mean SSE4A